home *** CD-ROM | disk | FTP | other *** search
/ Power Programmierung / Power-Programmierung (Tewi)(1994).iso / fortran / mslang / fort_bmp / bmp30fmt.txt < prev    next >
Text File  |  1993-07-14  |  7KB  |  141 lines
  1.  
  2.     This file is paraphrased from files obtained from the Microsoft
  3.    Knowledge Base on Compuserve.
  4.  
  5.     A Windows Device Independent Bitmap (DIB) v3.0 is composed of
  6.    four sections: BITMAPFILEHEADER, BITMAPINFOHEADER, color table, and
  7.    finally the image data itself. Each of these sections is defined below.
  8. -----------------------------------------------------------------------------
  9.  
  10.  BITMAPFILEHEADER  [3.0]
  11.  
  12.  The BITMAPFILEHEADER data structure contains information about the type,
  13.  size, and layout of a device-independent bitmap (DIB) file.
  14.  
  15.  The BITMAPFILEHEADER data structure contains the following fields:
  16.  
  17.  Field        Datatype          Description
  18.  -----        --------          -----------
  19.  bfType       2 byte character  Specifies the type of file. It must be BM.
  20.  bfSize       4 byte integer    Specifies the size of the file in bytes.
  21.  bfReserved1  2 byte integer    Is reserved and must be set to zero.
  22.  bfReserved2  2 byte integer    Is reserved and must be set to zero.
  23.  bfOffBits    4 byte integer    Specifies in bytes the offset from the 
  24.                 beginning of the file to the actual bitmap.
  25.  
  26. -----------------------------------------------------------------------------
  27.  
  28.     The next section can be either a BITMAPINFOHEADER or BITMAPCOREHEADER.
  29.  The BITMAPCOREHEADER is for Presentation Manager v1.1 compatability and
  30.  is not described in this document.
  31.  
  32.  BITMAPINFOHEADER contains the following fields:
  33.  
  34.  Field           Data type       Description
  35.  -----           ---------       -----------
  36.  biSize          4 byte integer  This field defines the size of the  
  37.                  BITMAPINFOHEADER in bytes. 
  38.  biWidth,        4 byte integer  Define the width and the height of the bitmap
  39.  biHeight                        in pixels. They are DWORD values for future
  40.                  expansion, and the code in Windows versions 
  41.                  3.0 and 3.1 ignores the high word (which 
  42.                  should be set to 0).
  43.  biPlanes        2 byte integer  Should always be 1. All DIB definitions rely 
  44.                  on biBitCount for color resolution definition.
  45.  biBitCount      2 byte integer  Defines the color resolution (in bits per 
  46.                  pixel) of the DIB. Only four values are 
  47.                  valid for this field: 1, 4, 8, and 24. 
  48.  biCompression   4 byte integer  Specifies the type of compression. Can be 
  49.                  one of three values: BI_RGB, BI_RLE4, or 
  50.                  BI_RLE8 (0, 1, or 2). The most common and 
  51.                  useful choice, BI_RGB, defines a DIB in which 
  52.                  all is as it seems. Each block of biBitCount
  53.                  bits defines an index (or RGB value for 24-bit
  54.                  versions) into the color table. The other two
  55.                  options specify that the DIB is stored (or will 
  56.                  be stored) using either the 4-bit or the 
  57.                  8-bit run length encoding (RLE) scheme that 
  58.                  Windows supports. 
  59.  biSizeImage     4 byte integer  Should contain the size of the bitmap proper 
  60.                  in bytes (i.e. without headers or color 
  61.                  table). 
  62.  biXPelsPerMeter,4 byte integer  Define application-specified values for the
  63.  biYPelsPerMeter                 desirable dimensions of the bitmap. This
  64.                  information can be used to maintain the 
  65.                  physical dimensions of an image across 
  66.                  devices of different resolutions. When
  67.                  not filled in, they should both be set to 0.
  68.  biClrUsed       4 byte integer  Provides a way for getting smaller color 
  69.                  tables. When this field is set to 0, the 
  70.                  number of colors in the color table is based 
  71.                  on the biBitCount field (1 indicates 2 
  72.                  colors, 4 indicates 16, 8 indicates 256, and 
  73.                  24 indicates no color table). A nonzero value 
  74.                  specifies the exact number of colors in the 
  75.                  table. So, for example, if an 8-bit DIB uses 
  76.                  only 17 colors, then only those 17 colors
  77.                  need to be defined in the table, and 
  78.                  biClrUsed is set to 17. Of course, no pixel 
  79.                  can have an index pointing past the end of 
  80.                  the table.
  81.  biClrImportant  4 byte integer  Specifies that the first x colors of the 
  82.                  color table are important to the DIB. If the 
  83.                  rest of the colors are not available, the 
  84.                  image still retains its meaning in an 
  85.                  acceptable manner. biClrImportant is purely 
  86.                  for application use; GDI does not touch this 
  87.                  value. When this field is set to 0, all the 
  88.                  colors are important, or rather, their 
  89.                  relative importance has not been computed.
  90.  
  91. -----------------------------------------------------------------------------
  92.  
  93.  Color Table
  94.  
  95.  The color table immediately follows the header information. No color
  96.  table is defined for 24-bit DIBs. The table consists of an array of
  97.  RGBQUAD data structures. Red, green, and blue bytes are in reverse order 
  98.  (red swaps position with blue) from the Windows convention. This is another 
  99.  leftover from Presentation Manager compatibility.
  100.  
  101.  The RGBQUAD data structure contains the following fields:
  102.          
  103.  Field       Data type    Description
  104.  -----       ---------    -----------
  105.  rgbBlue     Byte         Blue component of the color.
  106.  rgbGreen    Byte         Green component of the color.
  107.  rgbRed      Byte         Red component of the color.
  108.  rgbReserved Byte         Is not currently used and must be set to zero.
  109.  
  110.  This structure is repeated for as many colors as are in the table (except
  111.  for 24 bit/pixel DIBs which use the data itself to represent the colors
  112.  and ignore the color table).
  113.  
  114. -----------------------------------------------------------------------------
  115.  
  116.   The final section contains the data itself. The biBitCount parameter
  117.   specifies the format of the data. The four possible formats are 
  118.   described below.
  119.  
  120.   biBitCount   Data format
  121.   ----------   -----------
  122.       1        DIBs are stored using each bit as an index into the color
  123.            table. The most significant bit is the leftmost pixel.
  124.       4        DIBs are stored with each 4 bits representing an index into
  125.            the color table. The most significant nibble is the leftmost 
  126.            pixel.
  127.       8        These DIBs are the easiest to store because each byte is an 
  128.            index.
  129.      24        DIBs have every 3 bytes representing a color (r, g, b).
  130.  
  131.   The following rules apply to all formats:
  132.   
  133.   - Every scanline is DWORD-aligned (DWORD=4 bytes). The scanline is buffered 
  134.     to alignment; the buffering is not necessarily 0.
  135.   - The scanlines are stored upside down, with the first scan (scan 0)
  136.     in memory being the bottommost scan in the image.
  137.     This is another artifact of Presentation Manager compatibility.
  138.   - 64K segment boundaries are not respected; scanlines can cross such
  139.     boundaries (unlike the device-dependent bitmap format that is
  140.     buffered to 64K boundaries).
  141.